A method of this type is used in particular in interactive development environments. Currently there are a wide variety of interactive systems for commercial application, ranging from very expensive mainframe computers down to small PCs. For example, the programming system LISP (list processing) is one of the many systems of this type known at present. For example, in 1985 the so-called "Spice LISP" was implemented as a variant of "Common LISP" at the Carnegie-Mellon University (CMU) on a computer manufactured by Perq. Systems Corporation. The authors David B. McDonald, Scott E. Fahlmann and Skef Wholey describe under the title "Internal Design of CMU Common Lisp on the IBM RT PC", September, 1987, CMU-CS-87-157, the exact details for an implementation of "Common LISP" in a Mach operating system which is compatible with Berkeley Unix 4.3. In particular, beginning with page 35, it is stated that a large number of inquiry operations are required for function calls to determine the current status of the called function. The status of a called function or program element refers to its form in being, for example, interpretable code, source code, object code or code to be simulated. In-line operations are provided here for so-called evaluation of the arguments. Then so-called out-of-line operations are provided which are realized as a central function call program and have different program parts for a compiled function and a list to be interpreted. If the called function can be represented by a symbol, a link table can be used, which is constructed from double words and initially references the central function call program, which from case to case enters a reference to the function program.
An operating system platform based on a virtual machine is described by the authors Jose Alves Marques and Paulo Guides under the title "Extending the Operating System to Support an Object-Oriented Environment" in the Proceedings of Object-Oriented Programming: Systems, Languages and Applications (OOPSLA '89), ACM, 1st to 6th Oct. 1989, New Orleans, La., USA, on pages 113 to 122. Objects can be classified in their object classes on the basis of type definitions of the user, consisting of operations and attributes. The objects can be referenced as active or passive objects, in that each object notified to the system is assigned its own identifier in each case, so that objects can be called uniformly and transparently. Access transparency independent of residence in a mass storage means or a main memory allows a dynamic linking to be available to an execution system and erroneous object accesses to be detected. As a result of synchronizing rules for a synchronizable object, synchronization takes place in the case of contending accesses. Error transparency of the system is provided, in that an error containment can be defined for atomic objects. A virtual architecture is provided in which management areas (domains) can be defined. The address space is divided on the one hand into a virtual object memory for calls and instantiation of objects during the execution of a job, and on the other hand into a storage system for objects outside the execution of jobs. Operations for objects are identified using a method identification, by means of which a virtual address for the operation can be taken from a method table, which address is assigned to the operation as allocated method. Reference to the associated entry in the method table for the referenced method is made during dynamic linking. The object structure is formed on the one hand by data objects which contain instantiation data, and on the other hand by implementation objects which contain the execution code for all objects of a particular implementation type. A data block is used as information header, in which the information required by the system for an object, for storing it, for calling it and also for access protection for an object, is entered. When an object is called an object reference, an operation identification and also a parameter list is prepared by the calling activity for a system call. In the case of a remotely stored object, the activity is distributed among the remote system nodes in which the remote object is stored. When the object is searched for, first of all a context object table in which the information headers are referenced for the objects associated with the job context is searched. In the case of an implementation object, an attempt is made using a node object table to locate the sought object in its own node, possibly in another job context. In the case of a data object, a distinction is drawn between non-synchronizable, synchronizable and atomic objects, in that an object storage table is to be checked, in particular in the case of multiple copies for a non-synchronizable object.
A method is described by the authors J. P. Benkard and J. P. Gelb under the title "Automatic descriptor decoding" in IBM Technical Disclosure Bulletin, Volume 16, No. 1, June 1973, on pages 180 to 182, in which method an instruction is decoded, from which data are used which are to be interpreted by means of a data descriptor. It is to be possible to change the data descriptor during execution, so that it is always necessary to interpret it anew when decoding the instruction. An addition is given as an example in which the operands are examined step by step to determine, for example, whether a conversion from a fixed-point format to a floating-point format is required. For the decision a plurality of table-like filters are used, the table entries of which determine the handling to be executed for the data to be used, in particular correspondence tests, preparations, type checks and conversions.